IBIS Macromodel Task Group Meeting date: 11 August 2015 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Avago (LSI) Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC * David Banas Marc Kowalski Ericsson: Anders Ekholm IBM Steve Parker Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Nicholas Tzou Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp. James Zhou Andy Joy SiSoft: * Walter Katz * Todd Westerhoff * Mike LaBonte Synopsys Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong (Note: Agilent has changed to Keysight) The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - Curtis stated that he would not be able to attend the following meeting. Arpad said he would therefore be asking for a volunteer to take minutes. Randy said that he thought he would be available to take the minutes. -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - None ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Curtis: I received no feedback via email for last week's minutes. - Mike L.: Motion to approve the minutes. - Arpad: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: - Arpad: We had an email last week regarding the Backchannel issue. - Walter: I sent a private email to Ambrish, Radek and Arpad. - I stated that I do not want to continue working on perfecting a Backchannel BIRD. - We don't see sufficient interest from IC vendors and customers. - I've done significant work on this. - I think my proposal is a good approach. - I'm going to step back and let Ambrish and others come up with a new BIRD that meets the fundamental requirements in a way they feel comfortable with. - Ambrish: [summarizing discussions with Walter, et al.] - Simplify BIRD 147 to remove any complications with the stimulus of the back channel interface file. Generally what Walter's proposal did. - Also propose a simple Tx BCI file that will cover most current transmitters. - Analogous to Walter's second "pigeon" proposal. - Will also allow for any future BCI file that someone may want to propose. - Maintaining the position that the EDA tool will not have any involvement with the message other than passing it back and forth. - With these changes we will then reintroduce BIRD 147 to the ATM. - Arpad: Based on this discussion I will remove item #11 (SiSoft co-optimization proposal) from our tabled topics list. - Walter: Yes. - Arpad: Item #12, BIRD 147 will be untabled when Ambrish is ready to update us. Item #7: Info, Out, InOut BIRD draft. - Arpad: We had a good discussion last week. - We ended with the suggestion that people come up with ideas on how the goals of this proposal should be implemented in the spec. - Walter: What are the goals? What is the intent? - Arpad: I made a statement that the goal was to prevent the specification from undermining itself by allowing undocumented non-portable features. - Ambrish: The main goal is to somehow prevent a Model Specific parameter from influencing what the EDA tool does. - There is a lack of knowledge about what the tool would need to do. - Walter: So, "A model maker should not expect the EDA tool to do anything differently based upon the value of any Model Specific parameter." - Ambrish: Yes. - Walter: That's a fair statement. That's a simple statement. - I'm comfortable with that. - Radek: I believe the discussion went a bit further. - We generally agreed that some experimentation being done with Model Specific parameters is okay. - But, it's important that the user is aware that some EDA tools may be doing something specific. - Ambrish: You could make another section or branch for EDA specific parameters. - Once you put a Model Specific parameter in the model, then users expect all tools to read it and handle it the same way. That causes problems. - Walter: "The user shall not expect that the EDA tool will do anything differently based on the value of a Model Specific parameter." - But the user can still direct the EDA tool use a certain Model Specific parameter's value in a certain way. That's not a problem. - Discussion: Walter, Todd, John, Arpad and Ambrish all showed interest in the proposal for a separate top level branch for experimental, non-portable parameters. Fangyi and Bob did not support the idea. They felt that nothing was to be gained by the added complication. Both felt the existing Model Specific concept could be used for experimental parameters. Fangyi felt the committee was trying to place certain restrictions on the experimental phase. John replied that the top level branch would really only serve to document the experimental nature of the parameters to the EDA tool. Supporters felt the top level branch provided the flexibility and the documentation. Arpad and Ambrish suggested that using Model Specific parameters for experimental, tool-specific features was overloading the Model Specific concept and causing confusion for users. Mike L. pointed out that using normal Model Specific parameters for experimental features could result in EDA tools reading them and presenting them to users to make choices that might be unexpected. A suggestion was made for locating EDA tool specific branches underneath the Model Specific branch. Walter preferred the top level experimental branch concept because it minimizes the changes necessary if a parameter is later accepted as a Reserved parameter. - Arpad: [responding to objections to the new branch proposal] - We have come full circle now. - If you're saying we don't need a new branch, that's fine. - But now we need to go back and define explicit rules and regulations spelling out what the expectations are. - Todd: At the end of the day you have to do it one way or the other. - How much is about expectation, and how much is about notification? - John: If notification is the goal, that's hard to accomplish using Model Specific. - How do we achieve this goal? - Arpad: Now is a good stopping point. - Thank you all for joining. ------------- Next meeting: 18 August 2015 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives